home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93a.txt / 000029_icon-group-sender _Mon Jan 18 08:43:05 1993.msg < prev    next >
Internet Message Format  |  1993-04-21  |  5KB
  1. Received: by cheltenham.cs.arizona.edu; Mon, 18 Jan 1993 11:23:36 MST
  2. Message-Id: <9301181543.AA01233@turing.cse.nau.edu>
  3. From: sbw@turing.cse.nau.edu (Steve Wampler)
  4. Date: Mon, 18 Jan 1993 08:43:05 MST
  5. In-Reply-To: Michael Sperber's mail message of Jan 18,  1:52pm.
  6. X-Mailer: Mail User's Shell (7.2.3 5/22/91)
  7. To: sperber@soir.informatik.uni-tuebingen.de (Michael Sperber)
  8. Subject: Re: Pattern matching in Icon?
  9. Cc: icon-group@cs.arizona.edu
  10. Status: R
  11. Errors-To: icon-group-errors@cs.arizona.edu
  12.  
  13. On Jan 18 at  1:52pm, Michael Sperber writes:
  14. } 
  15. } Well, at least one person got it (partially) right.  I had't
  16. } thought of Prolog as the inspiration for the control structure
  17. } I had proposes, but in fact, a unification is what would happen
  18. } in pattern matching, albeit in a much more limited sense, that
  19. } is also easier and more straightforward to implement.
  20.  
  21. } As I keep saying (jeez, has NOONE here ever looked at Hope, Miranda,
  22. } ML or the like?!), the proposed scheme could be used to
  23. } implement structural recursion VERY elegantly - with the
  24. } added power of generators.
  25.  
  26. But - you seem to be saying that the language designer is going to
  27. implement *exactly* the pattern matching facility you want in
  28. *exactly* the right way - once you add something like that to
  29. a language, it's *very* hard to change!  What I'm saying is
  30. that Icon already has a facility that can not only do everything
  31. you want, with really very little effort (you write your pattern-matching
  32. functions once) but it also has *the ability to be extended* as you,
  33. the programmer, sees fit.
  34.  
  35. Furthermore, your proposed pattern matching construct violates
  36. syntactic consistency - it looks like something else (witness the
  37. confusion those of us who have used Icon extensively have with
  38. 'seeing' what it is you want) - normal Icon exprssions.  It also
  39. changes the structure of the language so that there are places where
  40. arbitrary expressions are allowed and not patterns, and places where
  41. patterns are allowed and not arbitrary expressions (with very little
  42. syntactic clues as to what is needed where!).
  43.  
  44. Finally, you're introducing a 'sublanguage' into Icon (just as the
  45. pattern matching of SNOBOL was a sublanguage to SNOBOL).  Icon is
  46. already a fairly complex language, I'm not convinced that adding
  47. syntax to support a fairly limited operation is worth it, *especially*
  48. given that Icon already has a more powerful capability with its
  49. case expression.
  50.  
  51. } Steve Wampler proposed ...
  52. } 
  53. } >I guess the only real debate is whether to add it into the language
  54. } >or not:
  55. } >
  56. } >   case s := <expression> of {
  57. } >      match_syntax_tree(s,"let") : {a := s.arguments
  58. } >        ...
  59. } >      }
  60. } >
  61. } >   ...
  62. } >
  63. } >   procedure match_syntax_tree(s, op)
  64. } ># match a pattern, in this case, the pattern is simple...
  65. } >      if type(s) == "syntax_tree" & s.operator == "let" then
  66. } >         return s
  67. } >   end
  68. } >
  69. } >not as visually pleasing as a new syntax would be, but I contend
  70. } >this would be more flexible and generalizes better than fixed
  71. } >patterns would...
  72. } 
  73. } This stuff looks extremely awkward to me, in fact even more awkward
  74.  
  75. You find adding two assignment operators to your original syntax
  76. 'extremely' awkward?  Why?  More awkward, yes.  But I don't see
  77. that as 'extremely'!  Or is that you're writing your own pattern
  78. matching function(s) that you see as awkward?  Again, you write them
  79. once, hide them away in a library, and presto, no difference there
  80. with having them built into the language -- except that you can
  81. *change* them!
  82.  
  83. } than doing the pattern matching explicitly.  It would mean having
  84. } separate procedures (with different names, too!) for each constructor
  85. } AND combination of constants/unknowns.  My proposal was exactly
  86.  
  87. Nonsense.  I named it 'match_syntax_tree'.  You could just as easily
  88. call it 'pat_match', or whatever, and implement an entire pattern matcher
  89. in the one procedure.  Yes, you have to *write* the procedure
  90. to do what you want, but as I said, I consider that flexibility a net
  91. win (in fact, personally, I find it a *huge* win - I *like* being able
  92. to describe *exactly* what I want!)  And you only have to write it *once*,
  93. anyway...  Plus you can have different pattern-matchers for different
  94. contexts!
  95.  
  96. } aimed at removing that syntactic clumsiness.  As I said (again,
  97. } and again), that's exactly why compilers are so much easier to
  98. } write and read in functional languages.  The way to go would
  99. } probably be using the variant translator feature of Icon to do
  100. } the job.  Anyone interested?  (If I'm not all alone with this, I
  101. } might actually get around to doing it, some day ...)
  102.  
  103. Now that I can see, particularly as an experiment - you could get the
  104. syntax you want that way, and Icon already has the capability semantically.
  105. The current syntax just doesn't bother me enough to justify my time on
  106. it though.  You'll still have to write the 'awkward' procedures for
  107. actually doing the pattern matching, of course.
  108.  
  109. } Cheers :-> Chipsy
  110.  
  111. -- 
  112.     Steve Wampler
  113.     {....!arizona!naucse!sbw}
  114.     {sbw@turing.cse.nau.edu}
  115.